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An Introduction to 
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in FORTRAN 


This text, intended for programmers, describes and 
illustrates the use of structured programming. The 
technique and its supporting practices are generally 
described in one chapter. A second chapter illus- 
trates the implementation of the technique in 
FORTRAN and is followed by a chapter presenting 
two sample programs. A knowledge of FORTRAN 
is assumed. 


Preface 


This text describes and illustrates the use of structured programming, a 
recently formalized programming style in which the structure of a program is 
made as clear as possible. Intended for programmers, the publication consists 
of three chapters: 


1. An expository chapter describes the technique, its supporting practices, 
and its use. General suggestions on getting started are also included. 

2. A reference chapter illustrates the implementation of the technique in 
FORTRAN. This chapter may be used as a starting point for establishing 
an installation’s own structured programming guidelines. 

3. A third chapter contains two sample programs written according to the 
techniques presented in the earlier chapters. 


Familiarity with programming concepts is necessary for the expository chap- 
ter, and knowledge of FORTRAN is needed for the reference and sample 
program chapters. 


Structured programming is also discussed in the following IBM publications: 


Improved Programming Technologies — An Overview (GC20-1850), 

Structured Programming (Independent Study Program) Textbook (SR20-7149), 
Workbook (SR20-7150), An Introduction to Structured Programming in COBOL 
(GC20-1776), An Introduction to Structured Programming in PL/I (GC20-1777). 


First Edition (July 1977) 


Requests for copies of IBM publications should be made to your IBM representative or to 
the IBM branch office serving your locality. 


A form for readers’ comments is provided at the back of this publication. If the form has 
been removed, address comments concerning the contents of this publication to IBM 
Corporation, Technical Publications/Systems, Dept. 824, 1133 Westchester Avenue, White 
Plains, New York 10604. 
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Chapter 1: An Overview of Structured Programming 


C 


Definitions 


This chapter contains various items of background information about struc- 
tured programming that should be useful. The topics include: 


Definitions 

A summary of the potential advantages of structured programming 
The relationship of structured programming to other improved program- 
ming technologies 

A sketch of the theoretical foundation of structured programming 
The basic control logic structures 

Additional control logic structures 

The GO TO question 

Segmentation 

Indentation 

Documentation considerations 

Efficiency considerations 

Getting started in structured programming 


After reading the material in this language-independent overview, the pro- 
grammer will be ready to study the reference material in Chapter 2 to see how 
structured programming can be implemented in FORTRAN, and to see some of 
the ideas illustrated in the two sample programs in Chapter 3. 


Structured programming is a style of programming in which the structure of a 
program (that is, the interrelationship of its parts) is made as clear as possible 
by using just three control logic structures: 


1. Simple sequence of functions 
2. Selection of functions (IFTHENELSE) 
3. Loop control, or iteration 


These three control logic structures can be combined to produce programs to 
handle any information processing task. Statements controlled by the selec- 
tion and loop structures are intended to make obvious the scope of influence 
of the structure. 


A structured program is composed of segments, which may range from a few 
statements up to about a page of code. Each segment has just one entry and 
one exit. Such a segment, assuming it has no infinite loops and no unreach- 

able code, is called a proper program. When proper programs are combined 

using the three basic control logic structures (sequence, selection, and itera- 

tion), the result is also a proper program. 


An important characteristic of a structured program is that it can be read in 
sequence, from top to bottom, without a great deal of the skipping around 
through the program that is typical of other programming styles. This feature 
is important because full comprehension of what a function does is easier if all 
the statements that influence its action are physically close by. Top-down 
readability is one consequence of using only three control logic structures, and 
of avoiding the GO TO statement except in very special circumstances, such 


Potential Advantages 


as the simulation of control logic structure in a programming language that 
lacks it. 


A program written according to these principles not only has a structure, it 
clearly exhibits that structure. 


A program written in this style tends to be much easier to understand than 
programs written in other styles. Easier understandability facilitates code 
checking, partly because structured programming concentrates on one of the 
most error-prone factors in programming, the logic. As a result, the program 
testing and debugging time may be reduced. 


An easy-to-read program composed of well-defined segements tends to be 
simpler, faster, and less expensive to maintain. These benefits derive in part 
from the fact that since the program is to a significant extent its own docu- 
mentation, the documentation is always up to date; this is seldom true with 
conventional methods. 


Structured programming offers these benefits, but it should not be thought of 
as a panacea. Program development is still a demanding task requiring skill, 
effort, and creativity. 


Relationship of Structured Programming to Other Improved Programming Technologies 


Structured programming is compatible with and supportive of other improved 
programming technologies, although distinct from them. Other technologies 
and the relationship of structured programming to them may be sketched 
briefly. 


Top-down program development involves writing and testing the highest level 
segments of a program first, in contrast to the more common method in the 
past, bottom-up development. This approach has the benefits of giving the 
critical top segments the most testing, of giving earlier warning of problems 
with the interfaces between segments, and of spreading the debugging and 
testing Over a greater part of the development cycle. 


Structured programming and top-down program development both emphasize 
the importance of segments that interact in precisely understood ways. Both 
involve looking at a program as a hierarchy of segments that are related to 
each other in a tree-like fashion. 


Hierarchy plus Input-Process-Output (HIPO) is an approach to functional 
specification and documentation of programs. Each function is designed 
using a HIPO diagram, in which inputs and outputs are listed and the process- 
ing that is to be carried out is specified. A visual table of contents diagram 
points to the HIPO diagrams in the package and therefore shows the functions 
and subfunctions to be carried out by the various parts of a program, and the 
relationship between them. At the detailed design level, it also shows the 
hierarchy of segments. 


Structured programming, as the term is used in this publication, refers pri- 
marily to the coding phase rather than the design phase of the program 
development cycle. HIPO is one good way to approach the design task, and 
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one that is complementary to structured programming. For additional inform- 
ation on H/IPO, see HIPO — A Design Aid and Documentation Technique 
(GC20-1851). 


A structured walk-through is a review session in which the orginator of 
program design material or code explains it to colleagues. The intent is to 
detect errors and deviations from standards and to ensure understandability. 
Errors are corrected after the walk-through as early in the process as possible, 
when they are least expensive to correct. 


Structured programming, with its emphasis on easy readability of programs, 
increases the effectiveness of structured walk-throughs. 


A development support library consists of a machine-readable library that 
contains the current versions of all project programming data. It also consists 
of external library binders that contain current listings of all library members 
and archives consisting of recently superseded listings. Besides providing easy 
accessibility of materials, this library helps assure that the latest versions of 
programs are always used. 


Structured programming, with its insistence on segmentation of programs, fits 
in well with development support libraries, although such libraries are useful 
with any style of programming. 


The chief programmer team concept involves programming with teams of at 
least three members: chief programmer, backup programmer, and program 
librarian. The team may also include other programmers, nonprogramming 
analysts, and end users. The chief programmer is responsible for the design 
and coding of all programs produced by the team, either writing or personally 
checking every piece of code. The program librarian maintains the develop- 
ment support library. 


Structured programming is well suited to chief programmer team methods, 
since it facilitates one key element, that of code review by the chief 
programmer. 


Structured Programming Theory 


The Structure Theorem 


The structure theorem states that any proper program can be written using 
only the control logic structures of sequence, selection (IFTHENELSE), and 
iteration. 


A proper program is defined as one that meets the following requirements: 


1. It has exactly one entry point and exactly one exit point for program 
control. 


2. Paths from the entry to the exit lead through every part of the program; 
therefore, the program has no infinite loops and no unreachable code. 
This requirement is, not a restriction but simply a statement that the 
structure theorem applies only to meaningful programs. 


The three basic control logic structures are defined as follows: 


Sequence is simply a formalization of the idea that unless otherwise stated, 
program statements are executed in the order in which they appear in the 
program. Although this is true of all commonly used programming languages, 
the fact is not always realized that sequence is a control logic structure. In 
flowchart terms, sequence is represented by one function after the other, as 
shown in Figure 1. A and B are anything from single statements up to 
complete subprograms; the concern is only with the abstract idea of a proper 
program, regardless of its size and internal complexity. A and B must both 
be proper programs in the sense just defined (one entry and one exit). The 
combination of A followed by B is also a proper program, since it also has 
one entry and one exit. This concept can be shown pictorially, as in Figure 2, 
where the outer box indicates that the combination of A followed by B can 
be treated as a single unit for control purposes. 


Figure 1. Flowchart for the control logic structure sequence 


Figure 2. Two proper programs in sequence 


Selection is the choice between two actions based on a predicate; this struc- 
ture is called IFTHENELSE. The usual flowchart notation for selection is 
shown in Figure 3, where p is the predicate and A and B are the two 
functions. 
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Figure 3. Flowchart for the control logic structure selection 


The iteration structure, used for repeated execution of code while a condition 
is true (also called loop control), is the DOWHILE. In the flowchart in 
Figure 4, p is the predicate and A is the controlled code. 


Figure 4. Flowchart for the control logic structure iteration, the DOWHILE 


A fundamental idea is that wherever a function box appears, any of the three 
basic structures may be substituted, and the result is still a proper program. 
For example, the function box in Figure 4 could be replaced with selection, 
producing the flowchart of Figure 5. The dotted lines show where another 
structure has been substituted for a function. Or, one function in a selection 
might be replaced with three functions in sequence, and the other replaced 
with an iteration, producing the flowchart of Figure 6. Flowcharts of arbi- 
trary complexity can be built up in this way. Figure 7 shows a flowchart with 
several control logic structures, drawn this time in top-to-bottom fashion. 
Other examples appear in Chapter 3. 


The ability to substitute control logic structures for functions and still have a 
proper program is basic to structured programming. This process may also be 
called the nesting of structures. 


Figure 5. An example of the combination of two control logic structures, in which the function controlled by a DOWHILE is an 
IFTHENELSE 


Figure 6. An example of the combination of control logic structures in which a sequence and an iteration are controlled by a | ) 
selection 
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( Figure 7. Another example of the combination of control logic structures 


Additional Control Logic Structures 


The DOUNTIL Structure 


The CASE Structure 
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Although all programs can be written using only the three basic structures, the 
use of a few others is sometimes helpful. 


The basic iteration structure is the DOWHILE, but a closely related structure, 
DOUNTIL, is sometimes used, depending on the procedure that is to be 
expressed and on the availability of appropriate language features. The 
flowchart is shown in Figure 8. 


Figure 8. Flowchart for the control logic structure iteration, the DOUNTIL 


The difference between the DOWHILE and DOUNTIL structures is that with 

the DOWHILE the predicate is tested before executing the function; if the 

predicate is false, the function is not executed. With the DOUNTIL, the 

predicate is tested after executing the function; thus, the function is always 

executed at least once, no matter whether the predicate is true or false. J 


It is sometimes helpful — from both readability and efficiency standpoints — to 
have some way to express a multiway branch, commonly referred to as the 
CASE structure. For example, if it is necessary to execute appropriate rou- 
tines based on a two-digit decimal code, it certainly is possible to write 100 IF 
statements, or a compound statement including many IF’s, but common sense 
suggests that there is no reason to adhere so rigidly to the three basic 
structures. 


The CASE structure uses the value of a variable to determine which of several 
routines is to be executed. The flowchart is shown in Figure 9. Observe that 
DOUNTIL and CASE are both proper programs. 


Efficiency and convenience dictate reasonable use of language elements that 

may carry out logic functions in ways slightly different from those of the three 

basic structures. FORTRAN examples include the use of the DO statement and . 
the logical IF statement. 


Figure 9. Flowchart for the CASE control logic structure 


Labels and GO TO Statements 


Structured programming has occasionally been referred to as ‘““GO TO-less 
programming”. Although well structured programs have few if any GO TO 
statements, assuming an appropriate programming language, the absence of 
GO TO’s can be misinterpreted, and this issue should be put in context. 


A well structured program gains an important part of its easy readability from 
the fact that it can be read in sequence, without skipping around from one 
part of the program to another. This characteristic is a consequence of the 
use of only the standard control logic structures (GO TO is not a standard 
control logic structure). This sequential readability, or ‘“‘top-down’’ readabili- 
ty, is beneficial because the human mind is limited as to how much detail it 
can encompass at once. The function of a statement can be grasped far more 
easily if it can be understood in terms of just a few other statements, all of 
which are physically close by. GO TO statements generally defeat this pur- 
pose; in extreme cases they can make a program essentially incomprehensible. 


Segmentation 
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The elimination of GO TO’s has sometimes been misunderstood as the goal of 
structured programming. Although good reasons exist for not wanting to use 
them, no extra effort is required to avoid them; they just never occur when 
the standard control logic structures are used. Naturally, if the chosen pro- 
gramming language lacks essential control logic structures, they have to be 
simulated, and GO TO’s are necessary; however, their use can be carefully 
controlled. 


In certain exceptional, situations the use of GO TO’s may improve readability 
as compared to other ways of expressing a procedure. Such examples, howev- 
er, do not usually occur in everyday programming. The impact of deviations 
from installation guidelines, such as using GO TO’s in other than prescribed 
ways, should be given careful consideration before such deviations are permit- 
ted. 


Easy program readability requires that the programmer should not have to 
turn a lot of pages to understand how something works. A practical rule is 
that a segment should not exceed a page of code, about 50 lines. In 
FORTRAN terms a segment can be a main program, a FUNCTION, or a 
SUBROUTINE. (The term segment as used here has nothing to do with the 
different meanings of the term in connection with the functions of operating 
systems or data base management systems.) 


Segmentation, however, is more than just breaking a program into page-size 
pieces. Three features that characterize good program segmentation can be 
identified: 


1. The segmentation should reflect the division of the program into pieces 
that relate to each other in a hierarchy, that is, a tree structure. This 
organization, which may be displayed with a HIPO hierarchy chart, makes 
it simpler to understand how the segments relate to each other. Further- 
more, the segments at the top of the hierarchy should contain high-level 
control functions, whereas the segments at the bottom should contain 
detailed functions. 


2. A well-designed segment carries out functions that are closely related to 
each other. The programmer can more easily understand it and be sure 
that it does what it is meant to do. Also, when changes have to be made, 
either during original programming or in maintenance, there is less 
chance of disturbing portions of the program that do not change. 


3. A well-designed segment communicates with other segments only in 
carefully controlled ways. Some proponents of structured programming 
urge that segments always consist of subroutines and that the only com- 
munication between them be through parameter lists, thus reducing the 
chance that segments will interact in unintended and undesirable ways. 


Indentation 


The use of indentation is important because consistent indentation enhances 
readability, so that the finished program exhibits in a pictorial way the rela- 
tionships among statements. A central idea is that all the statements con- 
trolled by a control logic structure should be indented by a consistent amount, 
to show the scope of control of the structure. Indentation can be a major 
benefit, as shown in Figure 10 by the skeleton programs in pseudocode. 
(Pseudocode is an informal means of expressing logic.) Both programs do the 
same processing, but the second is far easier to understand and, therefore, to 
verify for correctness. 


Figure 10. Nested IF pseudocode statement, with and without indentation 
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Establishing Indentation Guidelines 


Guidelines for indentation in FORTRAN programs are suggested in Chapter 2. 
Note, however, that these are only guidelines; each installation will need to 
establish local conventions. Variation from the suggested guidelines is not 
important as long as the installation conventions are followed consistently. 
For example, it is not of fundamental importance whether the statements 
controlled by an IF are indented four spaces, or three, or two. Arguments can 
be made for each, but no way is absolutely right. Within any one installation, 
however, some set of rules should be followed or the value of indentation will 
be lost. 


Creating a Structured Program 
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Structured programming, as the term is used in this publication, refers to the 
coding portion of the total program development cycle. It may help to sketch 
the cycle, indicating how structured programming relates to each phase. 


The program development process can begin when, in response to a statement 
of requirements, a specification is developed that states the objectives of the 
application. The next step is initial design, during which each major function 
is identified and then subdivided into lower level functions. HIPO diagrams 
are a design aid and documentation tool at this stage. It is important in initial 
design not to become enmeshed in low-level details; the strategy is to manage 
complexity by attacking the problem one level of detail at a time. 


Program design should not be expected to proceed in a straight-line fashion. 
The HIPO hierarchy chart may have to be drawn several times, as the expect- 
ed segment size or the implications of logic flow become clearer. The basic 
idea is to begin with a top-level attack, with little detail, and then fill in the 
successive levels, refining original plans as necessary until the design is. 


Once the initial design is complete, programmers refine the design to add the 
details necessary for the coding process. In detailed program design, addi- 
tional HIPO diagrams are created to specify further detail about each process. 
If flowcharts are used to express logic flow, they should include only the basic 
structures. Another technique used in the detailed design phase is pseudo- 
code, an informal means of expressing logic. Although HIPO diagrams can 
reduce the need for other documentation of logic flow, flowcharts and pseu- 
docode can be used with HIPO diagrams. 


In pseudocode the basic control logic structures and indentation are used ina 
carefully controlled way, but the programmer has discretion over everything 
else: elements of programming languages may be used, or mathematical 
notation if it is appropriate to the application, and so on. Pseudocode is 
similar to a programming language, but it is not compilable and is not bound 
by formal syntactical rules. Pseudocode is used to depict detailed logic while 
avoiding the distractions of the details of programming language require- 
ments; it is easier to modify than programming language statements. When 
detailed program design is finished, the translation from pseudocode to the 
chosen programming language is straightforward, since the most difficult part 
(the logic) is finished. Examples of pseudocode appear in the illustrations in 
Chapter 3. 


Documentation 


In the coding stage of program development, the techniques that have be- 
come identified with structured programming, as the term is used here, come 
into greatest prominence. Program statements implementing control logic 
structures are used, and they are indented to show the scope of influence of 
the structures; thus, the details of code are clearly related to the structure of 
the design. For ease of understanding, no structure is allowed to extend over 
a page boundary. The objective is to use meaningful variable and subprogram 
names, perhaps following conventions that suggest the functions of the data 
and procedures. Program segments are proper programs (one entry, one exit) 
and can be read in sequence from top to bottom. 


It is becoming increasingly common for completed code to be checked by 
another programmer, either in a structured walk-through or in some other 
kind of code-reading process. During fest, program errors are located, and a 
verification is made that the program performs according to specifications. 
With structured programs this stage may tend to take less time than before 
because errors can be located and corrected more rapidly in the more reada- 
ble structured code. 


Finally, the program has to be maintained over the period of its use. Specifi- 
cations change, equipment configurations are modified, and coding errors are 
discovered; these may require program modifications. Over the life of a 
major program, maintenance often requires more effort than the original 
program development. 


Structured programming facilitates program maintenance for much the same 
reason that it facilitates program testing: the program is easier to understand. 
Whether the original programmer or a different maintenance programmer is 
involved, changes are easier to make and are less likely to cause undesired 
effects elsewhere in the program. 


In summary, program development consists of requirements specification, 
initial design, detailed design, coding, test, and maintenance. The most 
difficult task is design, which properly should receive the most attention and 
effort, since errors are least costly to correct at this stage. 


How much documentation of a program’s logic is needed in addition to the 

program itself? In the past the argument has sometimes been made that the 
logic of a program should be documented with a complete set of flowcharts. 
This contention may need to be reevaluated for structured programs, which 
display their own logic better than conventional programs. 


To reduce the need for documentation of logic, the code should follow certain 
guidelines of good programming practice that for many years have been 
characteristic of the best programmers. Data and subroutine names should be 
as indicative as possible of the functions of the data items and program 
elements. Tricky coding should always be avoided. 
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Efficiency Considerations 
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When these and other commonsense principles have been followed and the 
program has been written according to the principles of structured program- 
ming (only a few control logic structures, use of indentation, and top-down 
readability), there will be little need for documentation of the logic flowchart 
type. (The need for documentation of function provided by HIPO hierarchy 
charts and HIPO diagrams, and traditional documentation such as data layout 
charts, data preparation instructions, etc., is not affected by structured 
programming. ) 


Programmers are sometimes concerned that structured programming techni- 
ques may result in object programs that run slowly or that create problems in 
a virtual storage system. There is nothing inherent in the structured program- 
ming approach that leads to inefficiencies; the use of a restricted set of 
control logic structures and of segmentation does not automatically carry any 
time or space penalty. 


Although no systematic study of many users has been made, some users have 
reported that usually no performance penalties result from structured pro- 
gramming techniques. If problems occur, they should be seen in the context 
of the full range of considerations that determine the effectiveness of a data 
processing operation. For instance, the ability to create programs on time 
may be much more important than a small object program speed penalty. 
Also, an apparently highly efficient program that is very difficult to maintain 
may not be really efficient in terms of total cost. Finally, efficiency always 
relates to a specific environment of compilers, hardware, and user code. 


If object program speed does become a problem, however, the following 
approaches may be considered. 


Identify those portions of the program that are most heavily used; various 
analysis programs may be helpful in doing so, for example, by providing 
counts of statement executions. A rather small part of the program will 
usually be found to have a large influence on speed. Concentrate on those 
few segments. It may be necessary to recode procedures to inline code, or to 
“‘unwind”’ short, heavily used loops. Consider the possibility of avoiding 
certain data conversions or language features that may adversely affect 
performance. Since usually only a small part of the program needs to be 
modified, this modification will ordinarily not take a great deal of effort. 


If excessive paging in a virtual storage system is a problem, the basic solution 
is to place procedures that are used together in the same virtual storage page. 
Again, analysis programs can help. Structured programming can actually be a 
benefit in this kind of tuning, since heavy use of subroutines is encouraged. 
Of course the scope of the data references must be considered; extensive use 
of COMMON Storage is generally considered inadvisable. Furthermore, 
performance problems can seldom be predicted in advance, no matter what 
coding techniques are used. Because of the ease of maintaining (changing) 
structured programs, the likelihood is that performance problems can be more 
easily corrected. 
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Getting Started in Structured Programming 


One way to evaluate structured programming in an installation follows: 


e Management authorizes the use of structured programming in a project. 
The first structured programming project should be neither trivial nor 
extremely difficult, but rather one of normal size and level of difficulty. At 
least two programmers should be assigned to the project so that they can 
check each other’s code. 


e Programmers assigned to the project familiarize themselves with the 
subject. Some installations have implemented structured programming on 
their own; others have found that attending a class was necessary. 


eA set of guidelines for the initial effort is established. The guidelines in 
Chapter 2 on FORTRAN implementation can be used; many installations 
will prefer to establish their own. The guidelines for the first project 
should avoid extending the permissible control logic structures; uncont- 
rolled extensions can easily destroy the value of structured programming. 
Some programmers find it helpful to summarize the guidelines in the form 
of a checklist or a simple illustrative program. 


e After the HIPO diagrams and visual table of contents are created, pseudo- 
code or flowcharts can be used for detailed logic, if appropriate. The code 
is then written and the program tested. 


The evaluation process can be repeated and the guidelines modified until the 
programmers have sufficient experience with structured programming. At this 
time structured programming guidelines can be incorporated into the 
installation’s standards. 
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Chapter 2: Implementing Structured Programming Using FORTRAN 


Once the principles of structured programming are understood, writing 
structured programs in FORTRAN is a matter of habitually following a few 
simple rules. In FORTRAN the control logic structures other than sequence 
must be implemented using logical IF and GO TO statements; this can be done 
in a disciplined way, retaining most of the advantages of structured program- 
ming. 


Basic Control Logic Structures 


Sequence 


IFTHENELSE 


Sequencing is implemented in FORTRAN simply by writing statements in 
succession. 


The IFTHENELSE Structure tests a logical expression to determine which of 
two function blocks will be executed. 


The flowchart of the IFTHENELSE structure is shown in Figure 11. 


statement-1 


Figure 11. Flowchart for the IFTHENELSE 
The pseudocode of the IFTHENELSE is: 
IF condition-p 
THEN 
statement-l 
ELSE 
statement-2 


ENDIF 
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The IFTHENELSE control logic structure can be implemented in FORTRAN in 
the following form: 


IF (.NOT.(p)) go to XXX 


statement-1 


statement-n 
GO TO YYY 
XXX CONTINUE 


statement-2 


statement-q 


YYY CONTINUE 
XXX and YYY are statement labels assigned by the programmer. 


It is permissible to reverse the logic of the condition and drop the .NOT. if 
doing so improves understandability, as it often will. The CONTINUE is 
aligned with the IF; in the case of a nested IF, the CONTINUE will not be 
column 7. The statements controlled by the structure are indented three 


spaces. 


J 


When no ELSE path is to be executed, this statement can be written in the 
form: 


IF (.NOT.(p)) GO TO XXx 


statement-lL 


statement-n 
XXX CONTINUE 
XXX is a statement label assigned by the programmer. 


DOWHILE 


The DOWHILE structure tests a predicate and executes a function as long as 
the predicate is true. The flowchart is shown in Figure 12. 


& 
Figure 12. Flowchart for the DOWHILE 


The pseudocode for the DOWHILE is: 


DOWHILE p 
function 


ENDDO 
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A DOWHILE can be implemented in FORTRAN in the following form: 
XXX IF (.NOT.(p)) GO TO YYY 
statement-l 


statement-2 


statement-n 
GO TO XXX 
YYY CONTINUE 


The XXX and YYY labels are assigned by the programmer. 


Additional Control Logic Structures 
DOUNTIL 


The DOUNTIL structure executes a function and then tests a predicate to 
determine whether to repeat it again. The flowchart is shown in Figure 13. 


J 


6 . 
Figure 13. Flowchart for the DOUNTIL 


The pseudocode for the DOUNTIL is: 


DOUNTIL p 
function 


ENDDO 
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A DOUNTIL can be written in FORTRAN in the following form: 
XXX CONTINUE 
statement-l 


statement-2 


statement-n 
IF (.NOT.(c)) GO TO XXX 


XXX is a statement label assigned by the programmer. 


CASE 


The CASE structure selects one of a set of functions for execution, based on 
the basis of the value of a variable. The flowchart notation is shown in Figure 
14. This construct can be coded in FORTRAN using the computed GO TO 
statement, as follows: 


GO TO (a, b, c, .. .n), Kk 
a CONTINUE 
statement-al 


statement-a2 


statement-an 
GO TO p 

b CONTINUE 
statement-bl 


statement-b2 
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ZL 


statement-bn 


GO TO p 


n CONTINUE 
statement-nl 


statement-n2 


statement-nn 


p CONTINUE 


Figure 14. Flowchart for the CASE control logic structure 


Program Organization 


A structured FORTRAN program consists of a main program and usually a 
number of subprograms. The free use of subroutines to implement the 
division of a program into segments is encouraged. The linkage overhead is 
not burdensome in most modern compilers, and the advantages of good 
modularization are significant. 


No segment — main program or subprogram — should exceed one page of 
code, since longer programs are more difficult to understand. 


Communication between segments should be solely through SUBROUTINE or 
FUNCTION parameter lists, rather than through COMMON storage, since 
excessive use of COMMON creates interconnections between segments in a 
way that hampers easy program maintenance. 


With minimum use of COMMON, it is less likely that a change in one segment 
will have an unexpected and harmful effect on some other segment. 


Indentation and Readability Guidelines 


No standardization of indentation and readability conventions has developed 
so far, and there seems to be little pressure for it as long as consistent stan- 
dards are followed within any one organization. The key idea in devising 
these guidelines is the production of programs in which the visual layout of 
the program elements aids the reader in understanding program relationships 
and functioning. Some suggested ways of accomplishing this goal follow: 


e Comment lines can be used freely to group statements having related 
functions. 


e Statements are much easier to locate and to change if no more than one 
statement is written on a line. 


e Placing all FORMAT statements together at the beginning of the program 
rather than interspersing them throughout the program aids the visual 
indication of program relationships. 


e The scope of control of the simulated control logic structures is made 
clearer if the CONTINUE is aligned with the IF and the statements con- 
trolled by the structures are indented by some consistent amount. The 
suggested guideline is three columns, but the number is not critical as long 
as consistency is maintained within any one organization. 


e Similarly FORTRAN IF and DO statements can be indented three spaces 
with the starting position of the beginning statement determined by the 
location of the previous statements. 


e Permitting a CONTINUE only as the object of a GO TO. 


The sample programs in Chapter 3 illustrate many of these guidelines. 
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Names 


Comments 


Special Conditions 
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In devising names for data, considerable care should be exercised to make 
them as helpful as possible to the reader in understanding the function of the 
data elements. In spite of the FORTRAN limitation of six-character names, 
meaningful names can usually be chosen; for example, RESID is a better name 
for “‘residual’’ than R13XQ. 


Experience has shown that well structured FORTRAN programs can be largely 
self-documenting, assuming the use of descriptive variable names. Since 
FORTRAN names are necessarily so short, however, it is often helpful to place 
a block of comments at the beginning of a segment to define the meanings of 
the variable names. Many programmers also recommend an initial section of 
comments briefly stating the function of the program. 


Most programming environments allow for specified unusual conditions to 
interrupt the normal flow of processing and activate exception-handling 
routines. Common examples are end-of-file conditions and arithmetic over- 
flow. Whether the structure theorem applies to programs containing such 
elements depends on whether they violate the one-entry, one-exit principle 
and thus fail to be proper programs. Certain types of interrupts always break 
the normal flow; others may or may not, depending on how the program is 
written. 


The only FORTRAN feature in this category is the END = option in the READ 
statement, for specifying the action to be taken when the input end of file is 
detected. If only a few simple operations or none remain to be carried out 
when the end of file is found, it may be acceptable to transfer to a closing 
section of the program with the END =. In other cases, however, it may be 
preferable to set a flag so that DOWHILE or DOUNTIL logic can be used to 
complete processing. Setting such a flag involves the use of GO TO state- 
ments, which is unavoidable given the FORTRAN syntax, since the END = is 
essentially a GO TO. Both methods are illustrated in the sample programs in 
Chapter 3. 
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Chapter 3: Two Illustrative Programs 


The best way to get a quick idea of any programming technique is to see 
examples of programs that employ it. In that spirit, two illustrative programs 
are presented that have been written following the principles discussed earlier. 
The IBM FORTRAN IV (G1) Compiler (5734-F02) Release 2.0 was used to 
compile the examples in this chapter. The programs were executed under 
OS/VS2 Release 3.7 (MVS) and the TS0-3270 Structured Programming Facility 
(SPF) (5740-XT2). The programs were executed under VM/370 Version 2 
Level 0. 


The first program involves a very common and fairly simple operation in 
commercial data processing. Even if the reader’s primary interest is in mathe- 
matical and engineering uses of computers, the program provides a good 
introduction to the use of structured programming in FORTRAN. The second 
program, for solving simultaneous equations, is more representative of the 
way FORTRAN is commonly used and is somewhat more complex in that it 
involves a main program and three subroutines. 


A Two-Level Control Total Program 


One of the most common data processing operations is the preparation of a 
summary report providing totals broken down by several levels of control, as 
well as a final total. A two-level control total report illustrates the basic ideas 
and can easily be extended to any number of levels. In this example it is 
assumed that the only report needed is the summary; extension of the pro- 
gram to include other processing and the printing of a detail line for each 
input record would involve no conceptual difficulties. 


For concreteness, it is assumed that the major control is a sales district and 
that the minor control is a salesman number. Each record contains a district 
number, a salesman number, and a dollar amount. The transaction file has 
already been sorted into sequence on salesman within the district. To keep 
things simple, the printing of headings and the counting of lines on the pages 
are omitted. 


Figure 15 is a HIPO diagram for this processing. A pseudocode representation 
is shown in Figure 16. Notice how the logic is clearly exhibited by the use of 
indentation with the basic control structures of sequence, selection, and loop 
control. The DOWHILE is used for the loop control with the controlled code 
shown inline. The same logic is shown in flowchart form in Figures 17a and 
17b. Working either from the pseudocode or the flowchart, the FORTRAN 
program in Figure 18 is not difficult to prepare. 


Note the use of blank comment lines, lines containing nothing but a C in 
column 1, to group statements having related purposes for easy readability. 
All FORMAT statements have been placed together at the beginning of the 
program. The alternative approach of placing them immediately after the 
statements that reference them is less preferable since it would diminish the 
value of indentation in providing a visual indication of program relationships. 


The program fairly directly implements the pseudocode in setting a flag when 


the end of file is detected. Under FORTRAN syntax for the READ statement, 
this cannot be done without GO TO’s since the END = feature is, itself, 
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essentially a GO TO. The CONTINUE statement is not actually required here, 
but the use of a CONTINUE as the only allowable object of aGO TO or DO 
statement is recommended by many programmers as enhancing program 
maintainability. 


This program was run with a small sample of test data, producing the output 
shown in Figure 19. The program is quite rudimentary, since it does not 
include printing of headings, counting of lines, checking for sequence or other 
errors in the data, or any processing of the records other than the accumula- 
tion of totals. All of these operations can be included readily while still 
following structured programming concepts. 


Author: System/Program. eee 
DiagamiD:_'-0 = Name:__PREPARE-SALES-REPORT Description 
from 
Input operating Process Output 
system 


REPORT-FILE A 1. Open files & read 1st record 


SALES FILE 2. Initialize district fields See 
DISTRICT- 
DISTRICT 3. Perform until the district changes or there is EE TOTAL 
no more data: 
SALES- od 
DOLLARS 


. Initialize the salesman’s field 


PREVIOUS- 
SALESMAN 


(| SALES MAN. 
TOTAL 


b. Accumulate the salesman’s total until the 
salesman changes 


. Read the SALES-FILE 


. When the salesman changes print total & 
add to district total 


4. When the district changes or there is no more 


in —_—— 
an 


a. Print district total 


b. Accumulate final total 


5. When there is no more data print final total 


FINAL-TOTAL 


REPORT-FILE 
6. Close the files 


to 
operating 
system 


Figure 15. Detailed design level HIPO diagram for a two-level control total processing application 
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BEGIN SALES REPORT 
READ SALESMAN, DISTRICT NUMBER, DOLLARS 
ZERO FINAL TOTAL 
SET END OF DATA FLAG OFF 
DO WHILE NOT END OF DATA 
ZERO DISTRICT TOTAL 
MOVE DISTRICT NUMBER TO PREVIOUS DISTRICT 
DO WHILE DISTRICT = PREVIOUS DISTRICT 
AND NOT END OF DATA 
ZERO SALESMAN TOTAL 
MOVE SALESMAN TO PREVIOUS SALESMAN 
DO WHILE DISTRICT = PREVIOUS DISTRICT 
AND SALESMAN = PREVIOUS SALESMAN 
AND NOT END OF DATA 


ADD SALES DOLLARS TO SALESMAN TOTAL 
READ SALESMAN, DISTRICT NUMBER, DOLLARS 
IF END OF DATA 
SET END OF DATA FLAG ON 
ENDIF 
EN DDO 


WRITE PREVIOUS SALESMAN, SALESMAN TOTAL 
ADD SALESMAN TOTAL TO DISTRICT TOTAL 
ENDDO 
WRITE PREVIOUS DISTRICT, DISTRICT TOTAL 
ADD DISTRICT TOTAL TO FINAL TOTAL 
ENDDO 
WRITE FINAL TOTAL 
END SALES REPORT 


Figure 16. Pseudocode for a two-level control total processing application 
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Start job 


Open 
files 


Read 
SALES.-FILE 


Zero 


FINAL-TOTAL 


Print 


FINAL-TOTAL 


Close 
files 


Add 
DISTRICT -TOTAL 
to 

FINAL-TOTAL 


Print 
DISTRICT 
TOTAL 


SALES-TOTAL 


Process 
salesman 
totals 


Move 
DISTRICT to 
Previous- 

DISTRICT 


Zero 
DISTRICT 
TOTAL 


Terminate job 


Figure 17a. 


Flowchart for the mainline processing portion of 
a two-level control total processing application 


SALES-TOTAL 


Add 
S-TOTAL to 


D-TOTAL 


Print 
S-TOTAL 


F 


SALESMAN=P-SALESMAN 
and 


DISTRICT=P-DISTRICT 


Add 
S-DOLLARS 
to 
SALESMAN.- 
TOTAL 


Read 
SALES-FILE 


Move 
SALESMAN 
to 
P-SALESMAN 


S-TOTAL = SALESMAN-TOTAL 
D-TOTAL = DISTRICT -TOTAL 
P-SALESMAN = PREVIOUS-SALESMAN 
S-DOLLARS = SALES-DOLLARS 
P-DISTRICT = PREVIOUS-DISTRICT 
Zero SALES-TOTAL= 

S-TOTAL SALESMAN-TOTAL-PROCESSING 


DISTRICTN_ T 
P-DISTRICT 


F 


Figure 17b. Flowchart for the record processsing portion of a two-level control total processing application 
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C A PROGRAM TO PRODUCE A TWO-LEVEL SALES REPORT 


ANAANAANANANANAANANA 


1001 


1002 


1004 


1005 


1006 


1007 


Figure 18. 
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VARIABLE NAMES 


DIST DISTRICT NUMBER 

PDIST PREVIOUS DISTRICT 

SLSMN SALES MAN 

PSLSMN PREVIOUS SALESMAN 

DATAFG FLAG TO INDICATE THAT END OF DATA HAS BEEN REACHED 
DISTOT DISTRICT TOTAL 

SLSTOT SALESMAN TOTAL 

FINTOT FINAL TOTAL 

DOLLRS SALES DOLLARS 


INPUT IS IN ASCENDING SEQUENCE ON SALESMAN WITHIN DISTRICT 


INTEGER DIST, PDIST, SLSMN, PSLSMN 
REAL DISTOT, SLSTOT, FINTOT, DOLLRS 


FORMAT (15, 13, F7.2) 
FORMAT (1X, I5, F12.2) 
FORMAT (1X, 17X, 13, F12.2) 
FORMAT (1X, 32X, F12.2) 


READ (5, 10) SLSMN, DIST, DOLLRS 
FINTOT = 0.0 
DATAFG = 1 
CONTI NUE 
IF (DATAFG .NE. 1) GO TO 1007 
DISTOT = 0.0 
PDIST = DIST 
CONTI NUE 
IF (DIST .~.NE. PDIST .OR. DATAFG .NE. 1) GO TO 1006 
SLSTOT = 0.0 
PSLSMN = SLSMN 


CONTINUE 
IF ( DIST .NE. PDIST 
1 ~OR. SLSMN .NE. PSLSMN 
2 ~CR. DATAFG .NE. 1) GO TO 1005 


SLSTOT = SLSTOT + DOLLRS 
READ (5, 10, END = 1004) SLSMN, DIST, DOLLRS 
GO TO 1003 
CONTINUE 
DATAFG = 0 
GO TO 1003 
CONTINUE 
WRITE (6, 20) PSLSMN, SLSTOT 
DISTOr = DISTCT + SLSTOT 
GO TO 1002 
CONTI NUE 
WRITE (6, 30) PDISTI, DISTOT 
FINTOT = FINTOT + DISTOT 


GO To 1001 
CONTI NUE 
WRITE (6, 40) FINTOT 
STOP 
END 


Structured program for a two-level control total processing application 


G1 
52 
69 


18 
52 


36 
39 
50 


Figure 19. 


20357 
110.00 
134.65 
if 448.02 
207.69 
185.60 
2 393.29 
194.15 
121.40 
51.80 
5 367.35 
1208.66 


Illustrative output from the two-level control total program of Figure 18 


Solving a System of Simultaneous Equations by the Gauss-Seidel Method 


This example is for the benefit of readers more concerned with technical 
applications. It assumes some familiarity with simultaneous linear algebraic 
equations and with their iterative solution by the Gauss-Seidel method. 


As many as 80 equations in 80 unknowns are to be permitted; the actual size 
N, which may be smaller than 80, is read from the first data card. This card 
also specifies MAXIT, the maximum number of iterations to be permitted, the 
convergegice criterion EPSLON, and the largest absolute value permitted of an 
element in the system array, BIGGST. The array is initialized to zero, so that 
only the nonzero elements need be read; row and column numbers are 
checked for validity as the data cards are read. All data values are checked 
and errors reported, but the solution is not attempted if any errors are found. 


Not all systems of simultaneous equations can be solved by the Gauss-Seidel 
method. After the coefficients and constant terms have been read, a check is 
made to determine that the main diagonal element in each row is larger in 
absolute value than the sum of the absolute values of the other coefficients in 
the row. If not, the error is reported and the solution is not attempted. 


The actual solution proceeds in a succession of sweeps. Starting with all zeros 
for the unknowns, new values for all unknowns are computed in one sweep. 
A variable named RESID holds the largest difference between the old and new 
values of unknowns. When this residual is found to be less than the conver- 
gence criterion, the system has been solved. If convergence cannot be 
achieved in the specified maximum number of iterations, the nonconvergence 
is reported. 


If all data values are acceptable, if the system is suitable for solution by the 


Gauss-Seidel method, and if the solution converges, the values of the N 
unknowns are printed as the solution. 
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Figure 20 shows pseudocode for the method of solution that is to be used. 
Observe how the logic of the solution is displayed, without distracting details. 
For example, the precise form of switch-setting is left to be detailed in the 
program. Likewise, in the procedure for reading the data, the line ‘IF data 
card invalid” appears. Although this line conveys the meaning clearly, it does 
not specify exactly what tests are to be made; those details can be found in 
the program specifications and in the program. Note, too, that a summation 
sign denotes this commonly used mathematical function, which in the pro- 
gram becomes a simple DO loop. If it were necessary to keep the pseudocode 
in machine-readable form, as is sometimes the practice, the Greek symbols 
would naturally have been represented in some transliteration, or the loop 
could be shown in detail. 


This program is shown in Figure 21. The mainline logic, according to which 
the various tests are made to determine at each stage what further actions are 
possible, is made clear by the use of meaningful data names, simple 
IFTHENELSE logic, and consistent indentation. Observe the use of ordinary 
FORTRAN DO statements in a situation where their use is natural and easy to 
understand, and where some compilers may produce more efficient object 
code than if a DOWHILE or DOUNTIL were used. 


The subroutine READAT (for “‘read data’’) obtains the data and tests the 
validity of each element separately. The choice of how much testing to do is a 
design decision that is taken for granted here; if further tests, such as the 
reasonableness of the value N, were desired, they could be incorporated 
easily. 


The subroutine VALDAT (for “‘validate system’’) is called into play if it is 
determined that the individual elements are acceptable. This function could, 
of course, have been made part of READAT, which might then have been 
named something like REDVAL, or READAT could have called this subroutine. 
The form chosen was picked because it gives the clearest picture of the logic 
at the top level. 


The actual solution of the system, if it is found to be potentially solvable, is 
done with the subroutine named SOLVER. Observe the use of the DOUNTIL 
control logic structure to get one unconditional execution of the controlled 
code before testing the condition. Notice the use of two FORTRAN DO 
statements for heavily used loops in familiar matrix operations for which the 
DO statement is well suited. Notice the use of a FORTRAN logical IF state- 
ment where only one statement is to be controlled and the operation is in a 
heavily used inner loop. Finally, note the use of the built-in function AMAX!1 
to establish whether the newly computed difference between the old and new 
values of an unknown is greater than the previous value of RESID; this could 
also have been done with an IF statement. 


After the program is tried with various erroneous data to check the error- 
detection handling, it is tested with the system shown in Figure 22. Using a 
convergence criterion (IPSLON) of 0.01, the method finds the solution shown 
in Figure 23. 


C 


Open files 
Initialize bad data switch off 
Clear arrays 
Read data 
IF no errors in data 
THEN 
Validate system 
IF system is valid 
THEN 
Attempt to solve system 
IF solution converges 
THEN 
Print results 
ELSE 
Print 'did not converge' 
ENDIF 
ELSE 


Print ‘cannot solve this sytem by Gauss-Seidel' 


ENDIF 


ELSE 


Print 'bad data' 


ENDIF 


Close files 


Figure 20. 


Pseudocode for a solution of simultaneous equations by the Gauss-Seidel method (1 of 4) 
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Read data: 


Get N, maximum iterations, epsilon, biggest 
More data switch = yes 
DOWHILE more data remains 
Get a card 
IF more data remains 
THEN 
IF data card invalid 
THEN 
Print data values and error message 
Set bad data switch on 
ELSE 
Store element in array 
ENDIF 
ENDIF 


ENDDO 


Figure 20. Pseudocode for a solution of simultaneous equations by the Gauss-Seidel method (2 of 4) 
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C 


C 


Validate system: 


DO |= 1toN 


WHILE no bad rows have been found 
sum =2 | a : 
ifjl ij 
< 
IF [a,,| < SUM 
THEN 


Set bad row switch on 


ENDIF 


ENDDO 


Figure 20. 


Pseudocode for a solution of simultaneous equations by the Gauss-Seidel method (3 of 4) 
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Solve system: 


Iterations = l 


DOUNTIL iterations > max iterations or residual < epsilon 
Residual = 0 


DOI= 1toN 


sum = 2 rae: Pee a 
1fj “13°75 
Temporary = Aa ag - Sum) [ass 
Residual = max(residual, abs(temporary - x.)) 
x, = temporary 
ENDDO 


Add 1 to iterations 
If iterations >maximum permitted 
THEN 

Set no-converge switch on 
ENDIF 


ENDDO 


Figure 20. Pseudocode for a solution of simultaneous equations by the Gauss-Seidel method (4 of 4) 
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C A PROGRAM TO SOLVE UP TO 80 SIMULTANEOUS EQUATIONS 
C BY THE GAUSS-SEIDEL METHOD 


Cc 
Cc FCRTRAN VERSION 
Cc 
INTEGER I, J, N, MAXIT, BALCDAT, VALID, CNVRGE 
REAL A(80, 81), X(80), EPSLON, BIGGST 
Cc 
10 FORMAT (1X, I2, 1PE14.6) 
20 FORMAT ('0", "DID NCT CONVERGE IN ", I4, ‘ITERATIONS') 
30 FORMAT ('0', "CANNOT SOLVE THIS SYSTEM BY GAUSS-SFIDEL') 
4Q FORMAT ("0', "BAD DATA -- JOB ABORTED' ) 
Cc 
pO 1002 I= 1, 80 
X(I) = 0.0 
DO 1001 J = 1, 81 
A(I, J) = 0.0 
1001 CONTI NUE 
1002 CONTINUE 
Cc 
BADDAT = 0 
CALL READAT (A, N, MAXIT, EPSLON, BIGGST, BADDAT) 
IF (BADDAT .NE. 0) GO TO 1007 
VALID = 1 
CALL VALDAT (A, N, VALID) 
IF (VALID .NE. 1) GO TO 1005 
CNVRGE = 1 
CALL SOLVER (A, X, N, EPSLON, MAXIT, CNVRGE) 
IF (CNVRGE .NF. 1) GO TO 1003 
WRITE (6, 10) (I, X(I), I =1, N) 
GO TO 1004 
1003 CONTINUE 
WRITE (6, 20) MAXIT 
1004 CONTINUE 
GO TO 1006 


1005 CONTI NUE 
WRITE (6, 30) 
1006 CONTI NUE 
GO TO 1008 
1007 CONTINUE 
WRITE (6, 40) 
1008 CONTINUE 
STOP 
END 


Figure 21. Structured program to solve simultaneous equations by the Gauss-Seidel method (1 of 3) 
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SUBROUTINE READAT (A, N, MAXIT, EPSLON, BIGGST, BADDAT) 
INTEGER I, J, N, NPLUS1, MAXIT, BALCDAT 
REAL A(80, 81), EPSLON, BIGGST, TEMP J 


10 FORMAT (212, 2F10.0) 

20 FORMAT (212, F10.0) 

30 FORMAT (1X, ‘ERRCR IN CARD WITH I = 
1 I2, °, VALUE = °, 1PE14.6) 


READ (5, 10) N, MAXIT, EPSLON, BIGGST 
NPLUS1 = N+#1 
1001 CONTINUE 
READ (5, 20, END = 1004) I, J, TEMP 
IF ( (I .GE. 
-AND. (I .LE. 
-AND. (J .GE. 
-AND. (J «LF. NPLUS1) 
-AND. (ABS(TEMP) .LT. BIGGST) ) GO TO 1002 
WRITE (6, 30) I, J, TEMP 
BADDAT = 1 
GO TO 1003 
CONTI NUE 
ACI, J) = TEMP 
CONTI NUE 
GO TO 1001 


CONTINUE 
RETURN | ) 
END 


Figure 21. Structured program to solve simultaneous equations by the Gauss-Seidel method (2 of 3) 
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SUBROUTINE VALDAT (A, N, VALID) 
INTEGER I, J, N, VALID 
REAL A(80, 81), SUM 


I= 1 
CONTI NUE 
IF (VALID .NE. 1 .OR. I .GT. N) GO TO 1003 
SUM = 0.0 
DO 1002 J=1, N 
IF (I .NE. J) SUM = SUM + ABS(ACT, J)) 
CONTI NUE 
IF (ABS(A(CI, I)) .LT. SUM) VALID = 0 
I=I +1 
GO TO 1001 
CONTI NUE 
RETURN 
END 
SUBROUTINE SOLVER (A, X, N, EPSLON, MAXIT, CNVRGE) 
INTEGER I, J, N, ITERS, MAXIT, CNVRGE, NPLUS1 
REAL A(80, 81), X(80), SUM, TEMP, RESID 


NPLUS1 = N + 1 
ITERS = 1 
CONTINUE 


(ACI, NPLUS1) - SUM) / ACI, I) 
AMAX1 (CRESIC, ABS(X(I) - TEMP)) 
TEMP 


100 3 CONTINUE 


Figure 21. 


ITERS = ITERS + 1 
IF (RESID .GE. EPSLON .AND. ITERS .LE. MAXIT) GC TO 1001 
IF (ITERS .GT. MAXIT) CNVRGEF = 0 
RETURN 
END 


Structured program to solve simultaneous equations by the Gauss-Seidel method (3 of 3) 
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12.063 x 


-0.110 x, + 0.901 x 


aes 1.018 Xo - 4.200 + 0.110 


1.934 x, + 1.011 - 0.500 


2 


+ 6.914 + 0.100 


1 2 


-1.952 x1 + 2.139 + 5.000 


Figure 22. 


System of simultaneous equations used to test the program of Figure 21 


1. 493188E+00 
~1.947272E+00 


2.997915E+00 
-3.799566E+00 


Figure 23. 
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Output of the program of Figure 21 when run with sample data corresponding to the system of simultaneous 
equations shown in Figure 22 
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